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author: Flash 

Proof of concept for persistence using debugserver to get a process where we can run unsigned code. 

PoC targets iPhone 6+ on iOS 9 beta 3 (13A4293g). 

Outline: 

Connecting with debugserver 

There is only one binary that has the get-task-allow entitlements required for debugserver to be able to 
debug it: neagent. Both neagant and debugserver are on the DeveloperDisklmage where their hashes can 
be loaded from the Trustcache but the hash matching the current iOS version's DeveloperDisklmage is 
preloaded in the kernel (i.e. if you take a binary from the DeveloperDisk image for 9b3 and put them on a 
9b3 device, their signature will be accepted without mounting the disk image.). 

The debugserver can no longer spawn neagent but it can attach to it if it is already running or if it will run 
at some point (> debugserver *:PORT --waitfor neagent --attach=neagent). Assuming we can launch 
binaries with arguments at boot (see later), we can start debugserver, followed by neagent and have a 
process under debugserver's control. 

Controlling debugserver 

To control debugserver, we need to be able to send it arbitrary ascii (annoyingly including '$'s and '#'s 
which can't be put in domain names or urls). 

debugserver can be controller in two ways: either via a TCP connection from any host to a given port on 
the device (> debugserver *:PORT) or via a file on disk that debugserver has read/write access to and the 
client process has at least write access to (> debugserver /path/to/file). Unfortunately, with its further 
restricted sandbox, debugserver has no write permissions anywhere (at least, I couldnt find anywhere). 
However, we can set up debugserver as a Webserver and receive any HTTP(S) requests to localhost. It 
might be possible to do this another way by rewriting /etc/hosts but the best way I found was to use 
/System/Library/SystemConfiguration/PPPController.bundle/sbslauncher, which seems to be used to 
download vpn plugins. Running this binary from the command line allows us to make an http or https 
request to a url of choice with arbitrary http headers and an arbitrary http body (or it would do the body if 
we made a POST request). We can use this to send (but not read) commands from debugserver: 

>/System/Library/SystemConfiguration/PPPController.bundle/sbslauncher 
sbslauncher_type_vpnplugin_download subtype http ://1 27.0.0.1 '<dictxkey>x</key> 
<string>commands</stringx/dict>'. 

We don't need to read the response from debugserver (see below) but I think we could fudge it by 
setting syslog to also write to a file and turning on debug logs from debugserver so it prints to the syslog- 
out-file out all the packets it sends back so us. We can then use sed (another trusted ramdisk binary) to 
extract the parts of the response we need and then construct another call to sbslauncher. Each call to 
sbslauncher would have to end in a detach command to stop debugserver closing. This would simplify the 
controlling of debugserver but complicate the launching and co-ordinating of binaries (but should be 
possible). 

Its worth noting that, other than the + (an ACK) and - (a nACK) all commands must be of the format 
$command#CC where CC is the checksum of the command, debugserver happily ignores everything else. 
This is incredibly useful in this situation as it will simply ignore the extraneous bytes sent as part of the 
HTTP GET request. 

Getting shellcode execution 

We are now in the position where we can send arbitrary commands to the debugserver but not receieve 
them. We start our message by sending '+' to initiate comms, then we turn off AckMode and turn on 
debugging (this step may be mandatory to fix a timing issue, not fully explored yet). There seems to be 
another slight timing issue here so to ensure the '+' gets received we send this pattern twice: ['+', 
'QStartNoAckMode']. 

We next need to allocate memory for our shellcode, however, we can't receive the address of our 
allocation back from the debugserver. To get around this and defeat ASLR, we allocate a 10Mb buffer 
which gets allocated immediately after the slid neagent. This causes an address (0x100500000 in 64bit) to 
always be allocated, whatever the slide permutation. It is here we write our shellcode and jump to it by 
setting pc, sending 'c' for continue and then detaching. 

Unfortunately, this is not quite enough. Because we typically attach to neagent at some point between 
dyld starting and neagent's entry point being called dyld and any of the other libraries (particularly objc) can 
be in an inconsistent state so that when we call dlsym it can cause crashes. To solve this we need to allow 
execution to continue until neagents entry point has been reached. This is not straight forward as we have 
no information about neagent in memory. To solve this we put a breakpoint at where the entry point will be 
for every slide permutation. (Interstingly, there seems to be a memory corruption somewhere in 
debugserver; when you ask it to make lots of breakpoints with a OxIOOO-ish length it detects corrupted 
memory and crashes). After setting all the breakpoints, we continue ('c'), which causes neagent to run to 
main, then remove all the breakpoints as they affect us after if we do not. Now we are free to write to 
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memory and jump to pc. Note: I allocate the lOmb memory region for our shellcode before creating the 
breakpoints to ensure we don't mess up the heap first. 

Our debugserver command list now looks like (ignore the spaces and checksum values, I haven't 
calculated them here,): 

+ #QStartNoAckMode#00 + $QStartNoAckMode#00 
$QSetLogging:bitmask=LOG_ALLILOG_VERBOSEILOG_RNB_ALL;mode=asl#00 $_Ma00000,rx#00 
$<turn on 255 breakpoints>#00 $c#00 $<turn off 255 breakpoints>#00 $<send write command with bytes 
of shellcode>#00 $<set pc>#00 $c#00 $D#00 

The shellcode runs because of debugserver's run-unsigned-code entitlement (just like in the REDUX 
days) 

Shellcode to arbitrary execution 

This is not really part of the exploit, it is just details of the techniques used to expand shellcode 
execution. 

At the point we get execution, we have a valid stack pointer but nothing else. Using the 
shared_region_check_np syscall we can find the base address of the sharecache and parse the header, 

mapping and image info's to get the address of libdyld.dylib. We can then parse this to get the dyld 

section which includes the address of the dyld_lookup_function. Using this function we can lookup dlsym. 
Now we have all we need to read payloads off disk, link them and run them. 

Initiating everything at boot 

Presently, I require the spawning of a single binary with arbitrary arguments at boot, to bootstrap full 
execution. My PoC uses a #! script place at /sbin/mount_nfs (not present on disk but launchd attempts to 
start it at boot) of the form "#!/usr/bin/perl argl arg2 ..." where /usr/bin/perl is either a hard-link to the target 
binary or a copy of the target binary, /usr/bin/perl (not present on disk) is used as it is a built in exception to 
the interpreter sandbox rule. 

An alternative way is to use the dhcpd.conf file that will run commands when certain operations fail. See 
dhcp-eval manpage online. 

By taking launchctl off the update ramdisk for target iOS version (see 
extract_ramdisk_from_update_ramdisk.py on details of unpacking the ramdisk), we have a signed binary 
that is trusted by the kernel. This can be used to launch multiple binaries by creating a launch. plist for each 
one and setting the payload to be started on load (I used KeepAlive set to True to do this) and setting 
/usr/bin/perl to be a copy of launchctl and using "#!/usr/bin/perl load payloadl .plist payload2. plist ...". 

I have labelled the plists to be debug. plist (starts /var/mobile/Media/debugserver *:80 -waitfor _neagent 
-attach=_neagent), neagent.plist (/var/mobile/Media/_neagent) and client.plist 
(/System/Library/SystemConfiguration/PPPController.bundle/sbslauncher 
sbslauncher_type_vpnplugin_download subtype http ://1 27.0.0.1 '<dictxkey>x</key> 
<string>commands</stringx/dict>'). Note, I use _neagent instead of neagent just in case the neagent on 
device starts and debugserver tries to connect to that instead, it will fail because it has different 
entitlements than the neagent from the DeveloperDisklmage. 

Yay - execution: over and over and over again as I haven't set up any cleanup or launch conditions. 
Thats an excercise for the user. 

Setup: 

Required files: 

• debugserver and neagent from the DeveloperDisklmage. dmg specefic to the target iOS 
version. 

• launchctl from the update ramdisk extracted from /usr/standalone/update/ramdisk/*.dmg for 
the specific iOS version. Not required if you change the three process initiations. 

• /System/Library/SystemConfiguration/PPPController.bundle/sbslauncher (already present on 
disk) 

• launch plists for debugserver, _neagent and sbslauncher. 

• linker_32.dylib or linker_64.dylib 

• a payload 

On disk files 

For the PoC, most files live in /var/mobile/Media/ but they can live anywhere (other than /tmp of 
course...) 

• /var/mobile/Media/debugserver 

• /var/mobile/Media/_neagent 

• /var/mobile/Media/debug. plist 

• /var/mobile/Media/client.plist (sbslauncher) 

• /var/mobile/Media/neagent.plist 

• /var/mobile/Media/linker (linker_*.dylib) 

• /var/mobile/Media/payload (payload to run, e.g. kernel exploit etc.) 

• /usr/bin/perl (the copy of launchctl) 

• /sbin/mount_nfs (the #! script to start launchctl) 


Cleanup: 

After boot 

• Unload and stop any of the launchctl launched binaries 

• Remove cached version of network request: in a folder in 
/private/var/mobile/Library/com. apple. nsurlsessiond/ (specifically the tasks. plist but the whole 
thing should probably go) 

After uninstall: 

• Additionally to above 

• Remove all placed files from disk (obviously) 

• Might need to remove cached version of 'download' from debugserver 

• From itunesstored (based on its User-Agent) 

Todo: 

• Currently the payload runs twice at boot. The first time, almost immediatly. 

• experiment with delay time for indiviudal binaries, negant should probably have a small 
delay 

• Improve debug server commands, I'm not 100% I always hit the neagent entry point. This 
causes the binary to execute before injecting shellcode 

• Try and stop neagent exiting immediately. This would improve time for debugserver required 
to connect to it 

• Test dlopening an unsigned binary. It might simplify the linking of the payload. 

• Get it working on 32bit. 

• Automate the pulling of the correct files? 

• Improve reliability on boot. Code seems to be much more reliable executed manually then 
through launchctl on boot. This is likely due to the (un)ordered way launchctl starts them 
which can confuse things a little. It suceeds eventually though as launchctl keeps rebooting 
them. 

• Either mask debugserver from the logs or get it working without turning on logging. 

Future ideas: 

This can be transformed to be a user partition only persistence by finding a single launch point in the user partition. 
Ideas: 

- create and install a 'hidden' from springboard, 'system' (hidden from iTunes) app with the voip attribute that makes 
it start on boot. 

- Setup an update so that it attempts to run the updatebrain on boot (this probably requires stealth of files or 
injection to stop softwareupdated getting confused by the presense of an update on disk). This comes with the bonus 
that we can load a trustcache blob if debugerserver etc. are no longer present by default in the kernel. 

- Set up the filesystem to trigger the userspace dhcpd.conf file (rather than the /etc/dhcpd.conf one) 


Things looked at that either never panned out or were not used or followed up: 

• These might be useful in the future to come back to if need be. 

• Modifying the /etc/hosts file to help get a process connect to the debugserver. 

• To talk to debugserver: 

• using "mobilesafari -u url" looks like it visits a url of choice but we can't seem to trigger it fully. 
Additionally it will unlikely send #'s as part of the url 

• setting the Accept-Language part of the HTTP Get by setting the current language in (i think) 
.GlobalPreferences. plist. This can likely contain our arbitrary commands but may confuse 
other things. 

• I also tried setting DYLDJNSERTJJBRARIES (both from the command line and from the control of 
debugserver) to load an unsigned dylib in to neagent that would run once the debugger was attached. I feel 
this should work but I couldn't get dyld to map it (errored out on an mmap) 

• Worth looking at: what is sbslauncher actually used for? Its has a few different subcommands that may be 
useful for something. 

• Connections stored in /private//var/mobile/Library/com. apple. nsurlsessiond/ are attempted every boot... 


